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DETAILED ACTION 

1. The response filed on 7/26/07 has been received and considered. Claims 1-17 
are presented for examination. 

Continued Examination Under 37 CFR 1.114 

2. A request for continued examination under 37 GFR 1.114, including the fee set 
forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this 
application is eligible for continued examination under 37 CFR 1.1 14, and the fee set 
forth in 37 CFR 1 .17(e) has been timely paid, the finality of the previous Office action 
has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 7/26/07 
has been entered. 

Drawings 

3. The objections to the drawings recited in the 2/26/07 Office Action have been 
withdrawn in response to the amendments to the drawings filed 7/26/07. 

Claim Objections 

4. Claim 1 is objected to because of the following informalities. Appropriate 
correction is required. 

5. Claim 1 , line 6 recites, "validating, in the device emulator, to which action", it 
would be better if written, "validating, in the device emulator, which action". 
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6. Claims 10 and 17 recite, "reading a defect configuration representing in a tagged 
text format...". While it is understood from the specification that this is directed to 
reading a defect XML configuration file (page 23, lines 14-16), the claim language could 
be confusing because it is unclear what the "defect configuration" is a "defect 
configuration" of. For example, the "defect configuration" could be a defect configuration 
of a device or a "defect configuration" of how the devices are configured in the network. 



Claim Rejections - 35 USC §112 

7. The Examiner would like to thank the Applicant for pointing out the typographical 
error made in the 2/26/07 Office Action. The rejections of Claims 1-9 and 14 were 
withdrawn in that Office Action. Any new rejections of the claims based upon the 
Amendment filed 7/26/07 follow. 

8. The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

9. Claims 1-12 are rejected under 35 U.S.C. 112, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. 

10. Claims 1-12 are directed to emulating devices "in a device connectivity protocol". 
It is unclear how a device can be emulated in a "protocol" since a "protocol" can be 
interpreted as a procedure that governs communications between devices in a system. 
The claim language makes it unclear as to whether the claim is directed to the 
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emulation of devices in a networl< wherein they communicate using a particular protocol, 
or intends to be directed to a different interpretation. 

1 1 . Claim 3, recites, "producing the default response for an action having a set of 
input and output parameters corresponding to state variables of the device...". It is 
unclear whether this "action" refers to the "action" validated in Claim 1 , or a different 

"action". 

12. Claim 3 recites the limitation "the evented variables" in line 8. There is 
insufficient antecedent basis for this limitation in the claim. 

Claim Rejections - 35 USC § 102 

13. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(a) the Invention was known or used by others in this country, or patented or described in a printed 
publication in this or a foreign country, before the invention thereof by the applicant for a patent. 

14. Claims 1-3, 13, 15 and 16 are rejected under 35 U.S.C. 102(a) as being 
anticipated by Kim et al ("Design and Implementation of Home Network Systems Using 
UPnP Middleware for Networked Appliances", IEEE Transactions on Consumer 
Electronics, Volume 48, Issue 4, Nov 2002, page(s): 963 - 972). 

1 5. As to Claim 1 , Kim et al teaches: a method of generically emulating devices in a 
device connectivity protocol, the method comprising: processing in a device emulator a 
description of a device to be emulated in the device connectivity protocol, the 
description specifying a set of actions of the device to be emulated (Table 2; page 965, 
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column 1, paragraph 1; Section 4.2, paragraph 1; Figures 9 and 10 and descriptions); in 
response to receiving an action request at the device emulator per the device 
connectivity protocol, validating in the device emulator which action out of the set of 
actions specified in the description the action request matches (page 965, column 1, 
paragraph 4; Figure 2, "Action Invocation" loop; section 4.2, paragraph 4, lines 5-6); 
upon validating an action to v\/hich the action request matches, producing, at the device 
emulator, a default response, the response based on the description such that, through 
the response the device emulator emulates operation of the device to be emulated 
(page 965, column 1, paragraph 4; Figure 2, "Action Invocation" loop). 

16. As to Claim 2, Kim et al teaches: wherein producing the default response 
comprises producing a response message containing a default value consistent with a 
data type specified for a return parameter of the action in the description (page 965, 
column 1, paragraph 4; page 967, column 1, paragraph 3; Figure 10, "dataType"). . 

17. As to Claim 3, Kim et al teaches: wherein producing the default response for an 
action having a set of input and output parameters "corresponding to state variables of 
the device comprises: setting the corresponding state variables of the device to values 
of the respective input parameters contained in the action request (page 968, column 2, 
last sentence); producing a response with output parameters set to values of the 
corresponding state variables of the device (page 965, column 1, paragraph 2, lines 6-8 
and paragraph 4); and producing an eventing message if the action modified any of the 
evented variables (page 965, column 1, paragraph 4; page 967. column 2, last 
sentence). 
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18. As to Claim 13, Kim et al teaches: computer-readable media having stored 
thereon a software framework of a generic device emulator for execution on a computer 
to provide emulation of an operation of a device within a device connectivity architecture 
consistent with a textual description of the device, wherein the description of the device 
specifies data formats of requests and responses for a set of actions that the device is 
capable of (page 965, column 1, paragraphs 1 and paragraph 2, lines 5-8; Figures 9 
and 10 and descriptions), the generic device emulator comprising: program code for 
receiving action requests directed to the device within the device connectivity 
architecture (page 965, column 1, paragraphs 2-4; Section 4, paragraph 3; Figure 10 
and description); program code for validating whether an action request matches that of 
an action specified in the description (page 965, column 1, paragraph 4; Figure 2, 
"Action Invocation" loop; section 4.2, paragraph 4, lines 5-6) and program code for 
performing a default behavior producing a response for the action consistent with the 
data format specified in the description, thereby emulating operation of the device for 
the action (page 965, column 1, paragraph 4; Figure 2, "Action Invocation" loop, Figure 
10, "dataType"). 

1 9. As to Claim 1 5, Kim et al teaches: wherein performing the default behavior 
comprises producing a response message containing a default value consistent with the 
data format of the response specified for the action in the description (page 965, column 
1, paragraph. 4; page 967, column 1, paragraph 3; Figure 10, "dataType"). 

20. As to Claim 16, Kim et al teaches: wherein the program code for performing the 
default behavior for the action in which the data format of the request and response has 



Application/Control Number: 10/676,350 Page 7 

Art Unit: 2123 

a set of input and output parameters corresponding to state variables of the device 
comprises: program code for setting the corresponding state variables of the device to 
values of the respective input parameters contained in the action request (page 968, 
column 2, last sentence); and program code for producing the response with output 
parameters set to values of the corresponding state variables of the device (page 965, 
column 1, paragraph 2, lines 6-8 and paragraph 4). 

Claim Rejections ■ 35 USC § 103 

21 . The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

22. Claims 4, 5, and 14 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Kim et al as applied to claims 1 and 13 above, in view of Kumar et al (US Patent 
7,017,148). 

23. Kim et al teaches processing in a device emulator a description of a device to be 
emulated in a device connectivity protocol, the description specifying a set of actions of 
the device to be emulated, validating in the device emulator which action out of the set 
of actions specified in the description the action request matches and upon this 
validation, producing a default response at the device emulator. 

24. Kim et al does not expressly teach (claims 4 and 14) providing hooks to interface 
user-provided action response implementations, if any, for the set of actions; upon 
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validating the action request to match the action, first checl^ing whether there is a user 
provided action response implementation for the action; producing the default behavior 
response consistent with the description of there is no user-provided action response 
implementation and otherwise performing the user-provided action response 
implementation for the action; (claim 5) wherein the hooks interface user-provided 
action response implementation of at least one action out of the set of actions but not 
every action out of the set of actions. 

25. Kumar teaches a method and apparatus for UPnP device code generation that 
provides a time and cost effective solution for developing UPnP devices by eliminating 
stages of the software development cycle and allows the device developer to focus their 
attention on application-specific problems instead of worrying about UPnP (column 23, 
lines 13-34), wherein hooks are provided to interface user-provided action response 
implementations of at least one action out of the set of actions, but not every action out 
of the set of actions (column 6, line 28-column 7, line 14) wherein the developer is only 
required to write the portion of code to handle a particular function or event (user- 
provided action response implementation) while the code to handle the underlying 
UPnP functionality is automatically generated (default behavior). 

26. Kim et al and Kumar are analogous art since they are both directed to UPnP 
devices and their XML descriptions. 

27. It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the method of processing of a description in a device in a 
device connectivity protocol to produce a default response to emulate a device in a 
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connectivity protocol as taught in Kim et al to provide hool^s to interface user-provided 
action response implementations as taught in Kumar since Kumar teaches a method 
and apparatus for UPnP device code generation that provides a time and cost effective 
solution for developing UPnP devices by eliminating stages of the software 
development cycle and allowing the device developer to focus their attention on 
application-specific problems instead of worrying about UPnP (column 23, lines 13-34). 
Further, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made that the processing of the description document for a UPnP device 
as taught by Kim (Section 4.2, paragraph 1; Figures 9 and 10 and descriptions) would 
determine if there is a user-provided action response and produce the default response 
if there is no user-provided action response implementation or otherwise perform the 
user-provided action response implementation for the action since the description 
document will be processed in the same way regardless of how the actions have been 
specified. The processing will determine which action out of the set of actions in the 
description document matches the action request and perform the matching behavior 
whether it is a default behavior or a user-defined behavior. 

28. Claims 6, 7 and 9 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Kim et al as applied to claim 1 above, and further in view of Skingsley et al (US 
Patent 6,697,751). 

29. Kim et al teaches the testing of emulated devices in a device connectivity 
protocol (Figure 15). 
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30. Kim does not expressly teach (claim 6) applying a defect behavior to messages 
produced to emulate the device In the device connectivity protocol; (claim 7) wherein 
the defect behavior is applied to packets of a particular type; (claim 9) and randomly 
applying a defect behavior out of a set of defect behaviors to messages produced to 
emulated the device in the device connectivity protocol. 

31 . Skingsley et al teaches an apparatus for testing and/or monitoring the 
transmission of data packets by communications equipment including an emulator that 
simulates a variety of network conditions for a variety of packets that embed a range of 
protocols and over a range of types of networks (column 12, lines 31-33) that subjects 
packets to errors thereby allowing applications to review their methods for handling 
such network Interruptions which is valuable since present methods of testing network 
software may not expose potential failures (column 12, lines 38-43), wherein (claim 10) 
the emulator (); (claims 6, 7) applies defect behavior to messages produced to emulate 
the device in the device connectivity protocol, wherein the defect behavior is applied to 
the packet of a particular type (column 4, lines 1-12; column 12, lines 31-41; column 12, 
lines 50-60; column 13, lines 51-61); and (claim 9) and randomly applying a defect 
behavior out of a set of defect behaviors to messages produced to emulate the device 
in the device connectivity protocol (column 13, lines 63-66). 

32. Kim et al and Skingsley et al are analogous art since they are both directed to the 
testing of network devices in a device communications protocol. 

33. It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the testing of emulated devices in a device connectivity 
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protocol as taught by Kim et a! to Include applying defect behavior to messages 
produced to emulate the device in the device connectivity protocol, wherein the defect 
behavior is applied to packets of a particular type, and randomly applying a defect 
behavior out of a set of defect behaviors to messages produced to emulated the device 
in the device connectivity protocol as taught in Skingsley et al since Skingsley et al 
teaches an apparatus for testing and/or monitoring the transmission of data packets by 
communications equipment including an emulator that simulates a variety of netv\/ork 
conditions for a variety of packets that embed a range of protocols and over a range of 
types of networks (column 12, lines 31-33) that subjects packets to errors thereby 
allowing applications to review their methods for handling such network interruptions 
which is valuable since present methods of testing network software may not expose 
potential failures (column 12, lines 38-43). 

34. Claim 8 is rejected under 35 U.S.C. 103(a) as being unpatentable over Kim et al 
in view of Skingsley et al as applied to claim 6 above, and further In view of Kumar and 
UPnP Implementers Corporation ("UPnP Device Certification Process Document", 
Version 1.0, 2001), herein referred to as UPnPIC. 

35. Kim et al in view of Skingsley et al teach applying a defect behavior to messages 
produced to test an emulated UPnP device in a device connectivity protocol. 

36. Kim et al In view of Skingsley et al do not expressly teach wherein applying the 
defect behavior comprises invoking a user-provided implementation of the defect 
behavior. 
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37. Kumar teaches a method and apparatus for UPnP device code generation that 
provides a time and cost effective solution for developing UPnP devices by eliminating 
stages of the software development cycle and allows the device developer to focus their 
attention on application-specific problems instead of worrying about UPnP (column 23, 
lines 13-34), wherein user-provided action response implementations are added to the 
device description (column 6, line 27-column 7, line 14) wherein the developer is only 
required to write the portion of code to handle a particular function or event (user- 
provided action response implementation) while the code to handle the underlying 
UPnP functionality is automatically generated (default behavior). 

38. UPnPIC teaches the UPnP certification process that is used to determine if a 
device complies with the applicable UPnP standard wherein compliance indicates that 
different devices from different vendors support the same device standard and are 
interchangeable with respect to that standard (section 3.1, paragraph 1) wherein the 
certification testing of a UPnP device necessary to achieve certification includes 
protocol, syntax tests and semantic tests (section 5.1, paragraph 1; Figure 4), wherein 
the syntax tests are derived from the device descriptions with added annotations for 
testing (Figure 5; section 5,2, last paragraph, second bullet). 

39. Kim et al in view of Skingsley et al, Kumar and UPnPIC are analogous art since 
they are both to UPnP devices and their device descriptions. 

40. It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the application of defect behaviors to messages 
produced by emulated UPnP devices in a device connectivity protocol as taught in Kim 
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et al as modified by Skingsley et al to include adding user-provided implementations of 
device behaviors as taught in Kumar, wherein the user-provided implementation of the 
device behaviors would include such behaviors as defect behaviors, added to the 
device description for testing purposes as taught in UPnPIC, since the addition of user- 
provided defect behaviors in a device description for a UPnP device that is emulated in 
a device connectivity protocol would allow a device developer to study how the device 
functions in the presence of certain errors in its description and how errors will effect the 
device's communication with other devices in a network. 

41. Claims 10-12 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Skingsley et al in view UPnPIC. 

42. Skingsley et al teaches an apparatus for testing and/or monitoring the 
transmission of data packets by communications equipment including an emulator that 
simulates a variety of network conditions for a variety of packets that embed a range of 
protocols and over a range of types of networks (column 12, lines 31-36) wherein (claim 
10) the emulator reads a defect configuration representing a defect behavior to be 
applied to a type of packet transmitted from an emulated device per a device 
connectivity protocol (column 4, lines 1-12; column 12, lines 38-41 and 56-58; column 

1 3, lines 63-66; Figure 7); applying the defect behavior to the packet of a particular type 
before transmitting the packet (coluhin 12, lines 56-58; column 13, lines 51-61); 
transmitting the packets as modified by applying the defect behavior (column 12, lines 
58-60); (claim 12) and randomly applying a defect behavior out of a set of defect 
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behaviors to messages produced to emulate the device in the device connectivity 
protocol (column 13, lines 63-66). 

43. Skingsley et al does not expressly teach (claim 10) the defect behavior 
represented in a tagged text format, (claim 1 1) wherein applying the defect behavior 
comprises invoking a user-provided implementation of the defect behavior. 

44. UPnPIC teaches the certification testing of a UPnP device that includes protocol, 
syntax tests and semantic tests (section 5.1 , paragraph 1 ; Figure 4), wherein the test 
tool includes the protocol tests that are generated from the UPnP device architecture, 
syntax tests that are derived from the device descriptions with added annotations for 
testing, and semantic tests specified by the Working Committees (WC's) that may test 
combinations of states and actions, for example, to test if a VCR properly responds with 
an error to a specific action (Figure 5; section 5.2, last paragraph and bullets). UPnP 
further teaches that device descriptions are written in XML and that UPnP technology 
uses Internet components including IP, TCP, UDP, HTTP and XML (section 1, 
paragraph 2; section 2.1). It is understood that the device descriptions, written in XML 
are in a tagged text format. It is further understood that the protocol testing of the device 
occurs by sending test packets over the IP network using UPnP protocol from the test 
node to the UPnP device being tested as shown in Figure 4. Finally, it is understood 
that the device descriptions are "annotated" by a user. 

45. Skingsley et al and UPnPIC are analogous art since they are both directed to the 
testing of a device in a device connectivity protocol. 
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46. It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the application of a defect behavior to packets 
transmitted between networked computer components via a device connectivity protocol 
as taught in Skingsley et al to include wherein the defect behaviors are represented in a 
tagged text format and wherein the defect behaviors are user-implemented since 
UPnPIC teaches the testing of devices in a device connectivity protocol wherein the 
devices are described in XML descriptions that can be annotated for testing wherein it 
would be beneficial for the device developer to annotate the behaviors of a device under 
test to determine how the device will function In a network connectivity protocol in 
response to the invocation of particular behaviors such as behaviors that may invoke 
defects in the device. 

47. Claim 17 is rejected under 35 U.S.C. 103(a) as being unpatentable over Kim et al 
as applied to claim 13 above, in vieyv of Skingsley et al. 

48. Kim et al teaches the testing of emulated devices in a device connectivity 
protocol (Figure 15), wherein the emulated devices are UPnP devices described in XML 
tagged text (Figure 10). 

49. Kim et al does not expressly teach reading a defect configuration representing at 
least one defect behavior to be applied to a type of packet transmitted from the 
emulated device within the device connectivity architecture, applying the defect 
behavior to the packet of the particular type and transmitting the packet from the 
emulated device as modified by the defect behavior. 
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50. Skingsley et al teaches an apparatus for testing and/or monitoring the 
transmission of data packets by communications equipment including an emulator that 
simulates a variety of network conditions for a variety of packets that embed a range of 
protocols and over a range of types of networks (column 12, lines 31-33) that subjects 
packets to errors thereby allowing applications to review their methods for handling 
such network interruptions which is valuable since present methods of testing network 
software may not expose potential failures (column 12, lines 38-43), wherein (claim 10) 
the emulator reads a defect configuration representing a defect behavior to be applied 
to a type of packet transmitted from an emulated device per a device connectivity 
protocol. (column 4, lines 1-12; column 12, lines 31-36; column 12, lines 56-58; column 
13, lines 51-61); applying the defect behavior to the packet of a particular type before 
transmitting the packet (column 12, lines 56-58); and transmitting the packets as 
modified by applying the defect behavior (column 12, lines 58-60); (claim 11) and 
randomly applying a defect behavior out of a set of defect behaviors to messages 
produced to emulate the device in the device connectivity protocol (column 13, lines 63- 
66). 

51 . Kim et al and Skingsley et al are analogous art since they are both directed to the 
testing of network devices in a device communications protocol. 

52. It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the testing of an UPnP emulated device in a device 
connectivity protocol as taught in Kim et al to include reading a defect configuration 
representing a defect behavior to be applied to a type of packet transmitted from the 
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emulated device per the device connectivity protocol, applying the defect behavior to 
the packet, and transmitting the packet from the emulated device as modified by 
applying the defect behavior as taught in Skingsley et al since Skingsley et al teaches 
an apparatus for testing and/or monitoring the transmission of data packets by 
communications equipment including an emulator that simulates a variety of network 
conditions for a variety of packets that embed a range of protocols and over a range of 
types of networks (column 12, lines 31-33) that subjects packets to errors thereby 
allowing applications to review their methods for handling such network interruptions 
which is valuable since present methods of testing network software may not expose 
potential failures (column 12, lines 38-43). 



Response to Arguments 

53. Applicant's arguments filed 7/26/07, with regard to Kim et al (see pages 8-12) 
have been fully considered but they are not persuasive. 

54. Applicant argues that the recited sections of Kim do not teach or suggest, 
"producing, at the emulator device, a default response, the response based on the 
description, such that, through the response the emulator device emulated operation of 
the device to be emulated" (page 9). The Examiner contends that Kim does teach or 
suggest this limitation. Kim teaches a description of a device to be emulated in Figure 
10 which shows, for example, an air conditioner and toaster appliance emulator, 
wherein this description specifies a set of behaviors for the appliance to be emulated. 
When a user Invokes an action for a device, the state variables for the device are 
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updated (page 965, column 1, paragraph 4). The updating of these state variables is the 
response of the emulated device based on the description document of the behavior of 
the device (shown in Figure 10, for example), and through the updating of these state 
variables, the device is emulated. Further, Kim teaches that the device, or appliance, 
emulators "can be operated on a UPnP enabled or embedded device or PC using Linux 
or Win CE platform" (section 4.2, paragraph 1) which shows that the emulators are run 
in a computer environment. 

55. Applicant argues that the home server description of page 965 column 1 is 
clearly focused on using the home server to send messages to appliances in order to 
invoke actions in appliances and does not describe emulation or a response (page 10). 
The Exanniner contends that updating of the state variables, the response to an action 
invocation (page 965, column 1 , paragraph 4), describes the response from the 
appliance that is being emulated by an appliance emulator, as shown, for example, in 
Figure 10, the appliance emulator which sets forth the behaviors for the device to allow 
for its emulation. 

56. Applicant argues that Kim's home server is separate from the appliance 
emulators and therefore, cannot perform any emulation (page 10). The Examiner notes 
that the cited sections of Kim do not point to the "home server" to perform the emulation, 
the cited sections of Kim point to the "appliance emulators" that emulate the appliances 
in the home network that can be controlled through the home server as shown in Figure 
1. 
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57. Applicant argues that Kim's appliance emulators are each built for a specific . 
device emulation job and do not utilize a description to operate, and therefore, do not 
teach or suggest various "description" language of claim 1 (page 10, last paragraph). 
The Examiner contends that Kim's appliance emulators utilize descriptions to operate, 
as shown in Figure 10, which Is the XML description of the device emulator. Kim further 
teaches that the appliance emulators can be "operated" on a PC using a Linux or Win 
CE platform (section 4.2, paragraph 1). As to the emulators being built for a "specific" 
job, the Examiner contends that even though the preamble of claim 1 recites 
"generically emulating", nothing in the limitations of the claim that follow require that the 
device description be "generic" and not be specific to the device to be emulated. The 
claim language requires "a description of a device to be emulated... the description 
specifying a $et of actions of the device to be emulated". The Examiner contends that 
the device emulators in Kim teach this limitation. Further, there is no limitation in the 
claim language that recites "various" "description languages" or even "various 
descriptions" of a device. 

58. Applicant argues, "these differences make it difficult for Kim to demonstrate 
"generic emulation" and that it would be unlikely that different devices would be 
emulated on different platforms and with different GUI's and that Kim's teaching of 
disparate emulations would teach away from the utility of using a device description 
(page 11). The Examiner contends that Kim's appliance emulators utilize device 
descriptions to operate, as shown in Figure 10. As to "generic emulation", the Examiner 
contends that even though the preamble of claim 1 recites, "generically emulating", 
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nothing in the limitations that follow recite any "generic" device descriptions or any 
limitations that would describe "generic" emulation. As to different devices being 
emulated on different platforms and with different GUI's. The Examiner is unclear where 
these limitations are required in the claim language. 

59. Applicant argues that while Figure 1 0 shows XML descriptions of appliances, 
there is no indication in Kim that these descriptions are either "processed" or "validated" 
by the appliance emulators of Kim, nor are they used to emulate devices (page 11). The 
Examiner contends that Figure 10 shows device descriptions of an air conditioner and 
toaster that are "processed" to emulate an appliance. Further, Kim teaches that the 
appliance emulators can be "operated" on a UPnP-enabled embedded device, or PC 
using Linux or Win CE, therefore showing that the descriptions are "processed" to 
enable the emulation of the device. 

60. Applicant's arguments with respect to the rejections of Claims 6-12 and 17 under 
35 use 103(a) as being unpatentable over Krumel, in view of Kim and Dugan, have 
been considered but are moot in view of the new ground(s) of rejection. 

Conclusion 

61 . The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 
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62. Walker (US Patent 6,539,503) teaches the testing of a software program or the 
design of an electronic device by injecting a predetermined error pattern to determine 
whether the program or design responds appropriately to the error. 

63. Any inquiry concerning this communication or earlier communications from the examiner 
should be directed to Mary C. Jacob whose telephone number is 571-272-6249. The examiner 
can normally be reached on M-F 7AM-5PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Paul Rodriguez can be reached on 571-272-3753. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private 
PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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